home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 1 / Cream of the Crop 1.iso / PROGRAM / TP122792.ARJ / 12-27-92.TPC
Text File  |  1992-12-27  |  51KB  |  1,454 lines
  1.  
  2. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3.  
  4. Conference 4
  5. Date       12-21-92 08:06:00
  6. From       Dj Murdoch
  7. To         Mike Copeland
  8. Subject    Re: BP 7.0 IDE bug (Range checking)
  9.  
  10.   MO>    I have found a bug in the way the IDE handles compiler flags.
  11.  MO>Consider the following peice of code:
  12.  
  13.  MO>{$A-,B-,D-,E-,F-,G-,I-,L-,N-,O-,P-,Q-,R-,S-,T-,V-,X-,Y-}
  14.  MO>                                   ^^^^^
  15.  MO>                                   Note Range checking and Overflow
  16.  MO>                                   checking are off
  17.  
  18.  MO>{$M 65520,0,655360}
  19.  MO>type
  20.  MO>        PArrayPtr = ^PseudoArray;
  21.  MO>        PseudoArray = Array[0..0] of byte;
  22.  
  23.  MO>var
  24.  MO>    PA : PArrayPtr;
  25.  MO>    PA^[2] := 33;
  26.  MO>        ^ Does not compile, gives "Constant out of 
  27.  MC> range" on attempt to
  28.  MO>        compile this:
  29.  
  30.  MO>However, change the above code to this:
  31.  
  32.  MO>{$A-,B-,D-,E-,F-,G-,I-,L-,N-,O-,P-,Q-,R-,S-,T-,V-,X-,Y-}
  33.  MO>{$M 65520,0,655360}
  34.  MO>type
  35.  MO>        PArrayPtr = ^PseudoArray;
  36.  MO>        PseudoArray = Array[0..0] of byte;
  37.  
  38.  MC>    Thanks, Mark!  This is a good one to know about, since 
  39.  MC> (1) I just got BP7.0, and (2) I use this technique in my code...
  40.  MC>    ('Course, I haven't been able to free up 28meg on my HD 
  41.  MC> yet, so I haven't installed the darn thing... 8<}})
  42.  
  43. Don't worry about it - the behaviour is the same as in TP 5.5 & 6.0.  Because
  44. the declaration doesn't include the element 2, it's an error to reference it.
  45.  
  46.  
  47.  
  48. --- Msg V3.2
  49.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  50.  * Tossed by SFToss/286 v1.02a on 92/12/23  10:43:47
  51.  
  52. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  53.  
  54. Conference 4
  55. Date       12-22-92 16:27:00
  56. From       Dj Murdoch
  57. To         Wayne Boyd
  58. Subject    Re: Stack overflow
  59.  
  60.   WB> Why not just avoid recursion completely? You don't NEED to 
  61.  WB> recurse you know. For example...
  62.  
  63. I don't see how you'd do a recursive directory search by this means.  It's
  64. easy to simulate recursion with loops, but you really do need a stack somewhere.
  65.  
  66.  
  67. --- Msg V3.2
  68.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  69.  * Tossed by SFToss/286 v1.02a on 92/12/24  08:07:50
  70.  
  71. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  72.  
  73. Conference 4
  74. Date       12-22-92 17:23:00
  75. From       Dj Murdoch
  76. To         Joe Jared
  77. Subject    Re: HUFFMAN.PAS
  78.  
  79.   JJ>      Are you just using one node array?  If so, that 
  80.  JJ> explains everything. The huffman compression I'm using 
  81.  JJ> uses a combination of parent and son, and packs them based 
  82.  JJ> on which match comes up first.  If ANY portion of first 
  83.  JJ> match on either array is missed, the result will be faster 
  84.  JJ> but less than ideal compression. A problem parent or a 
  85.  JJ> problem child comes to mind if you are using both. 
  86.  
  87. I think there are lots of variations on Huffman compression.  We've obviously
  88. chosen different ones.
  89.  
  90.  
  91. --- Msg V3.2
  92.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  93.  * Tossed by SFToss/286 v1.02a on 92/12/24  08:07:50
  94.  
  95. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  96.  
  97. Conference 4
  98. Date       12-22-92 17:26:00
  99. From       Dj Murdoch
  100. To         Wayne Boyd
  101. Subject    Re: 7.0
  102.  
  103.   WB> Now, the question I have, though, is whether or not the 
  104.  WB> latest version has a compiler switch for OS/2? 
  105.  
  106. Nope!  TP 7 just produces real mode DOS apps.  BP 7 produces those, plus DOS
  107. 16 bit protected mode programs, plus Windows programs.  BP 7 includes essentiall
  108.  all of TPW 1.5 (with a newer compiler) plus TP 7.
  109.  
  110. There are language changes, but not huge ones.  There are new optimizations,
  111. but some of them may be ahead of their time:  Novell netware has bugs that
  112. mess up calculations in some BP programs run at full speed. There's an easy
  113. way to turn off the 386 register usage (just set Test8086 to 0 at the start
  114. of your program), but it's a real shame to have to do that.
  115.  
  116. The IDEs are a lot lot the TP 6 IDE, but with the rough edges removed.  They're
  117. really nice.
  118.  
  119. A number of bugs from my TP6 bug list have been fixed; I haven't tallied them
  120. all yet.
  121.  
  122. A number of new bugs have been introduced, too.  I think you're generally
  123. ahead in the bug department again, especially if you keep up on the bug fixes
  124. that have been posted here.
  125.  
  126. --- Msg V3.2
  127.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  128.  * Tossed by SFToss/286 v1.02a on 92/12/24  08:07:51
  129.  
  130. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  131.  
  132. Conference 4
  133. Date       12-22-92 17:35:00
  134. From       Dj Murdoch
  135. To         Jussi Vainionp{{
  136. Subject    Re: GRAPHICS mouse in TEXT mo
  137.  
  138.  DP> > It is called PASMOU.ZIP.  It is available on CRS and 
  139.  
  140. DP>If you can't find it, reply back to me and I will send it DP>in an UUencoded form.
  141.  
  142.  
  143.  JV>         Please send it!!!
  144.  
  145.  JV>  * Origin: * BCG-Box, Turku, Finland * (2:222/151)
  146.  
  147. If you do send it, please do it by netmail!  Posting UUE material here is
  148. not allowed.
  149.  
  150. --- Msg V3.2
  151.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  152.  * Tossed by SFToss/286 v1.02a on 92/12/24  08:07:51
  153.  
  154. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  155.  
  156. Conference 4
  157. Date       12-22-92 20:52:00
  158. From       Dj Murdoch
  159. To         Andrew J. Mead
  160. Subject    Re: BP 7 difference
  161.  
  162.   >  JM> RandSeed := 123;
  163.  >  JM> for i := 1 to 8 do writeln( random( 1000));
  164.  
  165.  >  JM> TP 5.5: 343 282 986 996 781 855 343  32
  166.  >  JM> BP 7.0: 859  80 869 854 317 257  20  46
  167.  
  168.  AJ>    I haven't verified this, but I have verified that TP7 
  169.  AJ> (as opposed to BP7) real mode apps follow the same random 
  170.  AJ> sequence as TP50, TP55, and TP60.
  171.  
  172. That's interesting!  Were you using exactly the sequence above, or different
  173. code?  If the same code, that would indicate that the RTL in TP7 is different
  174. from BP7. 
  175.  
  176.  
  177. --- Msg V3.2
  178.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  179.  * Tossed by SFToss/286 v1.02a on 92/12/24  08:07:51
  180.  
  181. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  182.  
  183. Conference 4
  184. Date       12-22-92 06:15:00
  185. From       Trevor Carlsen
  186. To         Keith Dombrowski
  187. Subject    Re: SB
  188.  
  189.  
  190.  
  191.  KD> What, by your/fido's description is a non-crippled
  192.  KD> reader/editor? How many lines, etc, must it support?
  193.  
  194. FidoNet does not have a defined length limit for messages.  Therefore any
  195. mailer that arbitarily imposes a defined limit is theoretically non-compliant.
  196. In practice the limit is available disk space.
  197.  
  198. Readers and editors are a different situation.  As they are not directly involve
  199.  in the network, they do no affect "pass-through" mail.  Therefore they only
  200. affect mail at the node where they are being used. The sysop and/or user then
  201. needs to make a decision as to whether or not they are useful if they have
  202. arbitary limits on message size.  I personally would not use a reader/editor
  203. if it could not handle the complete text of a message that would occupy all
  204. available RAM.  
  205.  
  206. This Pascal conference has a 16K limit on message size.
  207.  
  208. Moderator
  209.  
  210. --- TC-ED   v2.01  
  211.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  212.  * Tossed by SFToss/286 v1.02a on 92/12/24  08:08:19
  213.  
  214. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  215.  
  216. Conference 4
  217. Date       12-22-92 04:11:00
  218. From       Mark Ouellet
  219. To         Dj Murdoch
  220. Subject    Re: borland pascal 7.0
  221.  
  222.  
  223.     On 16-Dec-92, you, Dj Murdoch, of 1:249/99.5 wrote...
  224.  
  225.  DM> I don't think TD386.EXE will work with QEMM no matter what you do, but 
  226.  
  227.  DM> unless they've changed something, TD386.SYS will.  You load it to get 
  228.  
  229.  DM> access to the hardware debugging features of the 386 chip.  They should 
  230.  
  231.  DM> be available in TD and in TD286.
  232.  
  233. Thanks for the tip Dj.
  234.     I haven't tried it yet but maybe the DPMI add-on for Qemm can make a
  235. difference. I doubt it though. In any case i'm glad to know about the
  236. .SYS still being usefull with TD286!!!
  237.  
  238.         Best regards,
  239.         Mark Ouellet.
  240.  
  241.  
  242. --- Squish v1.01
  243.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/20.4)
  244.  * Tossed by SFToss/286 v1.02a on 92/12/24  08:08:47
  245.  
  246. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  247.  
  248. Conference 4
  249. Date       12-22-92 04:13:00
  250. From       Mark Ouellet
  251. To         Dj Murdoch
  252. Subject    Re: Pointers
  253.  
  254.  
  255.     On 16-Dec-92, you, Dj Murdoch, of 1:249/99.5 wrote...
  256.  
  257.  DM> Change this declaration to Array[0..65520] of byte, and your trouble 
  258.  
  259.  DM> should go away.
  260.  
  261. Yes Dj,
  262.     all the replies I got point in that direction. I still think turning
  263. Range-Checking off should also turn off warnings from the compiler.
  264. Either you give the user full control or you don't.
  265.  
  266.     Having to declare an array large enough is a minor setback but a
  267. setback non-the-less.
  268.  
  269.         Best regards,
  270.         Mark Ouellet.
  271.  
  272.  
  273. --- Squish v1.01
  274.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/20.4)
  275.  * Tossed by SFToss/286 v1.02a on 92/12/24  08:08:47
  276.  
  277. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  278.  
  279. Conference 4
  280. Date       12-22-92 04:16:00
  281. From       Mark Ouellet
  282. To         Rand Nowell
  283. Subject    Re: Strange Happenings!
  284.  
  285.  
  286.     On 16-Dec-92, you, Rand Nowell, of 1:161/710.0 wrote...
  287.  
  288.  RN> Hi Mark, please do! And let me know what the results are, I have used
  289.  RN> this procedure before and had no problems....(lucky??)
  290.  
  291. Ok Rand,
  292.     I'll try it out some time. Haven't had time yet!! I'll let you know
  293. how it turns out. If your extra "0" was caused by something else then it
  294. could be a simple trick to eliminate directories from the list.
  295.  
  296.         Best regards,
  297.         Mark Ouellet.
  298.  
  299.  
  300. --- Squish v1.01
  301.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/20.4)
  302.  * Tossed by SFToss/286 v1.02a on 92/12/24  08:08:47
  303.  
  304. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  305.  
  306. Conference 4
  307. Date       12-22-92 04:37:00
  308. From       Mark Ouellet
  309. To         Ken Burrows
  310. Subject    Re: Pointers
  311.  
  312.  
  313.     On 09-Dec-92, you, Ken Burrows, of 1:249/201.21 wrote...
  314.  
  315.  KB> Element [2] IS out of range of an array[0..0], use the array[0..$FFFE] 
  316.  
  317.  KB> and it will be in range. It cost nothing to type a large structure, and 
  318.  
  319.  KB> use a SLen variable to keep track of how many elements are actually 
  320.  KB> created on the heap.
  321.  
  322. Yes Ken,
  323.     but as I told Duncan, I thought it would only be logic to allow me
  324. to compile it. setting Range-checking off should also disable compiler
  325. warnings!!
  326.  
  327.         Best regards,
  328.         Mark Ouellet.
  329.  
  330.  
  331. --- Squish v1.01
  332.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/20.4)
  333.  * Tossed by SFToss/286 v1.02a on 92/12/24  08:08:47
  334.  
  335. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  336.  
  337. Conference 4
  338. Date       12-22-92 04:48:00
  339. From       Mark Ouellet
  340. To         Michel Dussault
  341. Subject    Re: Windows API Call
  342.  
  343.  
  344.     On 18-Dec-92, you, Michel Dussault, of 1:240/518.0 wrote...
  345.  
  346.  MD> Does somebody know why most of the calls to Windows API are pascal call
  347.  MD> type ????
  348.  
  349. Michel,
  350. Maybe to simplify MicroSoft's problems:
  351.  
  352.     C and C++ can be told to use Pascal convention when passing
  353.     parameters
  354.  
  355.     Pascal can't be told to use C convention.
  356.  
  357. So if you intend to compile assembler, Pascal or C routines useable by
  358. both you had better make it Pascal convention. Since it's the only
  359. standard they both can use.
  360.  
  361.         Best regards,
  362.         Mark Ouellet.
  363.  
  364.  
  365.  
  366.  
  367. --- Squish v1.01
  368.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/20.4)
  369.  * Tossed by SFToss/286 v1.02a on 92/12/24  08:08:47
  370.  
  371. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  372.  
  373. Conference 4
  374. Date       12-22-92 04:54:00
  375. From       Mark Ouellet
  376. To         Tom Lawrence
  377. Subject    Re: Speed wanted !
  378.  
  379.  
  380.     On 16-Dec-92, you, Tom Lawrence, of 1:2605/606.0 wrote...
  381.  
  382.  TL> Well, not quite.  Borland's move uses movsb, and for some reason 
  383.  TL> (probably a good one I'm not aware of), they point ds:si to the source 
  384.  
  385.  TL> variable, advance ds:si to the END of the source, then copy backwards 
  386.  
  387.  TL> (via std instead of cld).  Anyway, here's a replacement MOVE procedure 
  388.  
  389.  TL> that's twice as fast, since it DOES use MOVSW...  and also handles 
  390.  TL> moving an odd-number of bytes, as well:
  391.  TL> 
  392.  TL> Procedure FastMove(Var Source,Dest;Count:Word); Assembler;
  393.  TL> Asm
  394.  TL> push ds
  395.  TL> lds si,SOURCE
  396.  TL> les di,DEST
  397.  TL> mov cx,[COUNT]
  398.  TL> shr cx,1
  399.  TL> pushf
  400.  TL> cld
  401.  TL> rep movsw
  402.  TL> popf
  403.  TL> jnc @E
  404.  TL> movsb
  405.  TL> @E: pop ds
  406.  TL> End;
  407.  TL> 
  408.  
  409. Tom,
  410.     Borlands move procedure will also handle moves with overlaping
  411. memory regions like Moving A[2] to A[1] for 256 elements. Maybe that is
  412. why you noticed the reverse move in the code you examined. Not sure
  413. either if MOVE is an actual routine in the system unit or if it's
  414. inserted into the compiled program like inline or like a macro.
  415.  
  416.     BTW, your routine could be even faster on 386 CPUs and up if you
  417. checked for them and used a 32bit move. I guess the algorithm would be
  418. similar. First doing 32bit moves and then checking if the remaining
  419. number of bytes to move warrants a 16 bit move. Do a 16 bit move if it
  420. does. The do an 8 bit move if there is still data to be moved.
  421.  
  422.         Best regards,
  423.         Mark Ouellet.
  424.  
  425.  
  426. --- Squish v1.01
  427.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/20.4)
  428.  * Tossed by SFToss/286 v1.02a on 92/12/24  08:08:47
  429.  
  430. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  431.  
  432. Conference 4
  433. Date       12-23-92 07:59:00
  434. From       Dj Murdoch
  435. To         Howard Hamlin
  436. Subject    Re: BP 7.0
  437.  
  438.   HH> The problem has nothing to do with Qemm.  I'm using BP7 on 
  439.  HH> a 286-10 ( don't laugh...it's all I've got ) and I don't 
  440.  HH> use any memory managers.  The state of the shift key 
  441.  HH> becomes random when I run BP.EXE (TURBO.EXE is fine).  I'm 
  442.  HH> waiting until the folks at Borland are back from vacation 
  443.  HH> so I can find out what's going on with this bug.  By the 
  444.  HH> way...if you compile TVDEMO in protected mode the same 
  445.  HH> problem occurs so it seems to be a problem with Borland's 
  446.  HH> DPMI but I'm not sure. 
  447.  
  448. On a 286, changes from protected mode to real mode are very slow.  It's possible
  449. that BP is switching back and forth while getting keys, and losing interrupts
  450. during the transition.  I don't know if there's going to be any solution for
  451. this one.
  452.  
  453. One thing I don't think you've mentioned: have you got any TSR's or device
  454. drivers loaded beyond the bare minimum?  Make sure it happens on a clean system,
  455. or Borland will just tell you that the other software is causing the trouble
  456. (and it may well be true).
  457.  
  458. --- Msg V3.2
  459.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  460.  * Tossed by SFToss/286 v1.02a on 92/12/25  15:56:43
  461.  
  462. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  463.  
  464. Conference 4
  465. Date       12-23-92 08:04:00
  466. From       Dj Murdoch
  467. To         Andres Cvitkovich
  468. Subject    Re: Multiple overlays or DLL's?
  469.  
  470.   AC> IMHO this could be done using procedure/function 
  471.  AC> variables, where the 8088/86 routines are in one overlaid 
  472.  AC> Unit, and the 286/386 (386?) are in the other. A small 
  473.  AC> test routine at program start could initialize those 
  474.  AC> proc/func vars with the appropriate values for the 
  475.  AC> processor installed. Then, only one unit should be used at 
  476.  AC> runtime, saving precious memory (though both are in one 
  477.  AC> a-little- bit- bigger OVR file).
  478.  
  479. Yes, you're right.  I thought the question was about doing it with separate
  480. .OVR files.  Another way to do it with just one .OVR file is to put the procedur
  481. s & functions into an object; have a function at the beginning initialize
  482. the object according to the processor type.
  483.  
  484. --- Msg V3.2
  485.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  486.  * Tossed by SFToss/286 v1.02a on 92/12/25  15:56:43
  487.  
  488. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  489.  
  490. Conference 4
  491. Date       12-23-92 08:09:00
  492. From       Dj Murdoch
  493. To         Mike Copeland
  494. Subject    Re: ..
  495.  
  496.   DM>Here's a problem that lots of people would like to see 
  497.  MC> a nice solution 
  498.  DM>to:  a source code mangler.
  499.  MC>          ^^^^^^^^^^^^^^^^^^^^^
  500.  MC>    Dj, I must be really naive: WHY?  What's the use 
  501.  MC> of/purpose for such a program?  I just can't imagine 
  502.  MC> anything positive or good from such an exercise in programming...  8<{{
  503.  MC>    "lots of people"???  WHO?
  504.  MC>    I'm truly puzzled...
  505.  
  506. This is for people who want to release units but don't want to give away their
  507. secrets.  If they want to support all .TPU versions, they've got to release
  508. 8 or 9 different .TPU files now, but a single mangled source may be just as
  509. cryptic and yet recompile in any TP version.
  510.  
  511. --- Msg V3.2
  512.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  513.  * Tossed by SFToss/286 v1.02a on 92/12/25  15:56:43
  514.  
  515. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  516.  
  517. Conference 4
  518. Date       12-22-92 23:15:00
  519. From       Trevor Carlsen
  520. To         Joy Mukherjee
  521. Subject    crippled readers/mailers
  522.  
  523.  
  524.  
  525.  TC>> this regard and many moderators are now taking a stand on
  526.  TC>> this.
  527.  
  528.  JM> Many moderators can do whatever, but the software dictates 
  529.  JM> what everyone else can do.
  530.  
  531. That is true of course but if users refused to use inferior software, authors
  532. would very quickly get their act together.
  533.  
  534. Personally, I cannot understand why anybody would want to use software that
  535. will mean they miss parts of important messages because it cannot read all
  536. of a FidoNet legal message.
  537.  
  538. TeeCee
  539.  
  540. --- TC-ED   v2.01  
  541.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  542.  * Tossed by SFToss/286 v1.02a on 92/12/25  15:57:33
  543.  
  544. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  545.  
  546. Conference 4
  547. Date       12-23-92 14:02:00
  548. From       Trevor Carlsen
  549. To         Steve Connet
  550. Subject    Pointers
  551.  
  552.  
  553.  
  554.  > You'll need to put another pointer in the record...something like
  555.  
  556.  >Type CurrentPtr = ^EachRecord;
  557.  >     EachRecord = Record
  558.  >       Dummy : Integer;
  559.  >       NextRecord: CurrentPtr; { this is so you can go forward }
  560.  >       PrevRecord: CurrentPtr; { this will let you go backward }
  561.  >     End;
  562.  
  563.  > Going backward is just like going forward, only the other
  564.  > direction. Same logic though...
  565.  
  566.  SC> So let's see, to go forward I would say (assuming Vars are defined):
  567.  SC>    MyPointer := MyPointer^.NextRecord;
  568.  
  569.  SC> And to go backward, would it be:
  570.  SC>    MyPointer := MyPointer^.PrevRecord;
  571.  
  572.  SC> But I am confused.  How does it know when to go backward or
  573.  SC> forward? Both assignment statements are the same.  Alas my
  574.  SC> frustration has caused me to tell you exactly what I'm
  575.  SC> trying to do.
  576.  
  577. Which will have the effect of allowing us to help now that we know exactly
  578.  what you are trying to do.  Firstly, I do not agree that a linked list is
  579. what you should be using.  An array of pointers is a far better way to do
  580. this but I will show how to use the linked list method as that is an ideal
  581. way to understand how pointers work.
  582.  
  583. In any linked list using the above record structure as an example, the PrevRecor
  584.  and NextRecord pointers have undefined values until your program defines
  585. them.  Let us start from scratch and create a linked list by reading a text
  586. file and as each string is read from that file we will place it into the list.
  587.  Here is a working and extensively commented example.
  588.  
  589.  SC> I have a list of names and index number of arbitrary length
  590.  SC> on disk. I want to read them all in (or as much as memory
  591.  SC> will allow).  They are to be displayed on the screen.
  592.  SC> Pressing the up arrow would scroll through the list in
  593.  SC> reverse, and pressing the down arrow would scroll through
  594.  SC> the list going forward.
  595.  
  596.  
  597. program LinkedListDemo;
  598.  
  599. uses crt;
  600.  
  601. type
  602.   { First create the linked list structure }
  603.   linePtr  = ^LineRec;
  604.   LineRec  = record
  605.                LineStr : string[80];
  606.                prev,
  607.                next    : linePtr;
  608.              end;
  609.  
  610. var
  611.   rootLine,           { a pointer to the first record }
  612.   currentLine,        { the current record            }
  613.   endLine   : linePtr;{ the last record in the list   }
  614.   f         : text;
  615.   ch        : char;
  616.  
  617. procedure ReadTextLine;
  618.   { creates space in memory for a new line and then reads the string }
  619.   { from the file and places it into that newly created space.       }
  620.   var
  621.     tempLine : linePtr;
  622.   begin
  623.     { Create the space for the new record and place this space       }
  624.     { address into the currentLine^.next pointer. First though we    }
  625.     { must check if there is enough memory for the record.           }
  626.     if MaxAvail >= sizeof(LineRec) then { there is enough memory } begin
  627.       new(tempLine);
  628.       if currentLine <> nil then
  629.         currentLine^.next := tempLine;
  630.  
  631.       { The space has now been allocated so make currentLine point to}
  632.       { the new space and check if it is the root entry by checking  }
  633.       { whether rootLine is nil or has a value and that its next     }
  634.       { pointer is also initialised.                                 }
  635.       currentLine := tempLine;
  636.       if rootLine = nil then
  637.         rootLine := currentLine
  638.       else if rootLine^.next = nil then
  639.         rootLine^.next := currentLine;
  640.  
  641.  
  642.       { Initialise the prev and next pointers in currentLine         }
  643.       currentLine^.prev := EndLine;
  644.  
  645.       { there is currently no next record so define the next pointer }
  646.       { as nil to indicate that this record is the last record in the}
  647.       { list. Also update the EndLine pointer;                       }
  648.       currentLine^.next := nil;
  649.       EndLine           := currentLine;
  650.       { The housekeeping complete, we can now read the line          }
  651.       readln(f,currentLine^.LineStr);
  652.  
  653.  
  654.     end else { there was not enough memory - remember? :-) } begin
  655.       writeln('Out of memory... aborting');
  656.       halt;
  657.     end;
  658.   end; { ReadTextLine }
  659.  
  660. procedure DisplayForward(startLine: linePtr; number: byte);
  661.   { Display number lines.  Normally this would be the size of your screen }
  662.  
  663.   var
  664.     x     : byte;
  665.     line  : linePtr;
  666.   begin
  667.     line  := startLine;
  668.     x     := 0;
  669.     { Create the loop that will display number lines }
  670.     while (line <> nil) and (x < number) do begin
  671.       inc(x);
  672.       writeln(line^.LineStr);
  673.       currentLine := line;
  674.       line := line^.next;  { goto the next record in the list }
  675.     end; { while }
  676.   end;  { DisplayForward }
  677.  
  678.  
  679. procedure  DisplayBackward(startLine : linePtr; number: byte);
  680.   var
  681.     x      : byte;
  682.     line   : linePtr;
  683.   begin
  684.     line   := startLine;
  685.     x      := 0;
  686.     with line^ do begin
  687.       while (prev <> nil) and (x < number) do { walk back through the list }
  688.  
  689.         inc(x);
  690.       { We have walked back and found where to start displaying from so }
  691.       DisplayForward(line,number);
  692.     end;
  693.   end;
  694.  
  695. begin { main }
  696.  
  697.   assign(f,'p:\prog\linklist.pas');
  698.   reset(f);
  699.  
  700.   { The first thing we MUST do is initialise the rootLine and endLine }
  701.   { pointers                                                          }
  702.   EndLine :=nil;  rootLine := nil;  currentLine := nil;
  703.  
  704.  
  705.   while not eof(f) do { read the file and create the linked list }
  706.     ReadTextLine;
  707.   close(f);
  708.  
  709.   Clrscr;
  710.   currentLine := rootLine;
  711.   repeat
  712.     DisplayForward(currentLine,22);
  713.     ch := ReadKey;
  714.   until currentLine = endLine;
  715.  
  716.   { To reclaim all the memory it is the simple matter of walking the list }
  717.  
  718.   { and disposing each record as you go.  eg.                             }
  719.  
  720.   repeat
  721.     currentLine := rootLine^.next;
  722.     dispose(rootLine);
  723.     rootLine := currentLine;
  724.   until currentLine = nil;
  725.  
  726. end.
  727.  
  728.  
  729.  
  730. TeeCee
  731.  
  732.  
  733. --- TC-ED   v2.01  
  734.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  735.  * Tossed by SFToss/286 v1.02a on 92/12/25  15:57:33
  736.  
  737. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  738.  
  739. Conference 4
  740. Date       12-23-92 18:16:00
  741. From       Trevor Carlsen
  742. To         Andres Cvitkovich
  743. Subject    Findfirst - SearchRec Name
  744.  
  745.  
  746.  
  747.  AC> Sorry for intercepting - but isn't it possible to fill the
  748.  AC> rest of "s" directly (since it's passed by value) or is
  749.  AC> "TempStr" really needed? And, what is "ch" needed for?
  750.  
  751.  AC> function FillStr (size: byte; s: string): string;
  752.  AC> begin
  753.  AC>   if length (s) < size then begin
  754.  AC>     FillChar (s[length(s)+1], size-length(s), 32);
  755.  AC>     s[0] := char(size);
  756.  AC>   end;
  757.  AC>   FillStr := s
  758.  AC> end;
  759.  
  760.  AC> You could also write the "s[0] := ..." outside the if
  761.  AC> statement to shorten the string if it's too long.
  762.  
  763.  AC> But - if I missed something, tell me.
  764.  
  765. All your points are correct.  I entered that on-the-fly so I guess I'll claim
  766. that as a reason for its sloppiness!  The ch was intended to allow any character
  767. to be used as a padder - then I didn't use it :-(.
  768.  
  769. TeeCee
  770.  
  771. --- TC-ED   v2.01  
  772.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  773.  * Tossed by SFToss/286 v1.02a on 92/12/25  15:57:33
  774.  
  775. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  776.  
  777. Conference 4
  778. Date       12-24-92 09:47:00
  779. From       Trevor Carlsen
  780. To         Terry Grant
  781. Subject    POS
  782.  
  783.  
  784.  
  785.  TG> Can someone give me a little more detail on how to use POS,
  786.  TG> It works fine during PLAIN ASCII searches, But not when I am
  787.  TG> looking for Multiple Words like Connect 2400 ? ( Worked fine
  788.  TG> for 2400 though ? )...
  789.  
  790. You make it next to impossible for anybody to help you by choosing NOT to
  791. show the faulty code.
  792.  
  793. Therefore the only advice we can give is to go back to basics and check out
  794. the correct syntax in your manual.
  795.  
  796. TeeCee
  797.  
  798. --- TC-ED   v2.01  
  799.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  800.  * Tossed by SFToss/286 v1.02a on 92/12/25  15:57:34
  801.  
  802. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  803.  
  804. Conference 4
  805. Date       12-24-92 17:32:00
  806. From       Trevor Carlsen
  807. To         Aaron Marasco
  808. Subject    BBS
  809.  
  810.  
  811.  
  812.  AM> It would be possible to create a DONE procedure of some sort
  813.  AM> that closes files, memory, etc. ie:
  814.  
  815.  AM> If (Not Carrier) and (Not Local) then
  816.  AM>  Begin
  817.  AM>    Done;
  818.  AM>    Halt(200); {Where 200 is a carrier drop - you can make ansi
  819.  AM>                message to them on their next call. . .}
  820.  AM>  End;
  821.  
  822. Better to make Done an exit procedure and then you do not need to call it
  823. explicitly. It also has the added advantage of doing your closing down housekeep
  824. ng regardless of where the program is when it terminates.  So -
  825.  
  826. var
  827.   OldExitProc : pointer;
  828.  
  829. procedure Done; far;
  830.   begin
  831.     ExitProc := OldExitProc;
  832.     { Do your closing down housekeeping here }
  833.   end;
  834.  
  835. Then in your initialisation routine -
  836.  
  837.   OldExitProc := ExitProc;
  838.   ExitProc    := @Done;
  839.  
  840. Then any halt automatically executes Done.
  841.  
  842. Simpler, cleaner, more reliable and more efficient.
  843.  
  844. TeeCee
  845.  
  846. --- TC-ED   v2.01  
  847.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  848.  * Tossed by SFToss/286 v1.02a on 92/12/25  15:57:34
  849.  
  850. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  851.  
  852. Conference 4
  853. Date       12-24-92 09:58:00
  854. From       Trevor Carlsen
  855. To         Jason Chancellor
  856. Subject    backspace
  857.  
  858.  
  859.  
  860.  JC> I (want)... a function that would take the last character
  861.  JC> off a string. Like a backspace would do.
  862.  
  863.   if byte(st[0]) > 0 then
  864.     dec(st[0]);
  865.  
  866. TeeCee
  867.  
  868. --- TC-ED   v2.01  
  869.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  870.  * Tossed by SFToss/286 v1.02a on 92/12/25  15:57:34
  871.  
  872. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  873.  
  874. Conference 4
  875. Date       12-24-92 11:07:00
  876. From       Trevor Carlsen
  877. To         Mike Copeland
  878. Subject    Re: ..
  879.  
  880.  
  881.  
  882.  DM>to:  a source code mangler.
  883.  MC>     ^^^^^^^^^^^^^^^^^^^^^
  884.  MC> Dj, I must be really naive: WHY?  What's the use of/purpose
  885.  MC> for such a program?  I just can't imagine anything positive
  886.  MC> or good from such an exercise in programming...  8<{{
  887.  
  888. A good mangler would make authors much more likely to distribute source code
  889. with their TPUs, thus enabling code libraries to be used across versions of TP.
  890.  
  891.  
  892. TeeCee
  893.  
  894.  
  895. --- TC-ED   v2.01  
  896.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  897.  * Tossed by SFToss/286 v1.02a on 92/12/25  15:57:34
  898.  
  899. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  900.  
  901. Conference 4
  902. Date       12-24-92 10:09:00
  903. From       Trevor Carlsen
  904. To         Andres Cvitkovich
  905. Subject    Fast Direct screen write
  906.  
  907.  
  908.  
  909.  AC> DirectVideo is part of the Crt Unit. Setting to False causes
  910.  AC> TP to write to stdout via DOS-calls. You could also use the
  911.  AC> file variable Output (=stdout), so you don't have to alter
  912.  AC> DirectVideo and can use both.
  913.  
  914.  AC> Sample:   Writeln (Output, 'This goes to stdout');
  915.  
  916. The above information, or some variant of it, has to be top of the hit parade
  917. in this echo for the most frequently given misinformation.
  918.  
  919. DirectVideo := false does NOT cause screen output to be done by DOS calls.
  920.  It means that the crt unit uses BIOS to do its work.  In fact stdout does
  921. not use DOS at all if the crt unit is in use unless you direct it to do so.
  922.  (See page 162 in the BP7 Language guide or page 199 in the TP6 Programmer's
  923. Guide.)
  924.  
  925. Your sample line, whilst certainly using stdout, does not necessarily use
  926. dos.  This is because the crt unit hijacks stdout itself.
  927.  
  928. TeeCee
  929.  
  930. --- TC-ED   v2.01  
  931.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  932.  * Tossed by SFToss/286 v1.02a on 92/12/25  15:57:34
  933.  
  934. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  935.  
  936. Conference 4
  937. Date       12-24-92 17:40:00
  938. From       Trevor Carlsen
  939. To         All
  940. Subject    New moderator
  941.  
  942.  
  943.  
  944. As of the 31st January 1993 I shall be resigning as Moderator of this echo.
  945.  Unfortunately the demands of my business interests mean that I cannot afford
  946. even the simple extra half hour required per day over and above normal echo
  947. reading.
  948.  
  949. Accordingly, I have approached Duncan Murdoch (Dj Murdoch) and asked him if
  950. he is willing to take over the responsibility.  He has agreed to do so and
  951. I will therefore accept netmail messages until the 15th January should anybody
  952. have any objections to this. (Rule 15 does not require this but in order to
  953. listen to and consider any objections anybody may have, I believe this to
  954. be a reasonable thing to do.)
  955.  
  956. Duncan is a well respected, long term contributor to the echo who has a vast
  957. wealth of knowledge about Turbo Pascal.  I have valued his netmailed messages
  958. to me on the odd occasions when my patience has been stretched to the limit
  959. by the occasional idiots no public echo can avoid.
  960.  
  961. I will remain a contributor to and reader of the echo, albeit in a reduced
  962. way.  The contest I started in September will remain current and I may even
  963. (with Duncan's permission of course) run others.
  964.  
  965. Finally my wife Georgie and I wish all of you a very Merry Xmas and a Happy,
  966. prosperous and healthy new year.
  967.  
  968. Moderator.
  969.  
  970. --- TC-ED   v2.01  
  971.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  972.  * Tossed by SFToss/286 v1.02a on 92/12/25  15:57:34
  973.  
  974. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  975.  
  976. Conference 4
  977. Date       12-24-92 20:06:00
  978. From       Trevor Carlsen
  979. To         Darcy Parker
  980. Subject    GRAPHICS mouse in TEXT mo
  981.  
  982.  
  983.  
  984.  DP> If you can't find it, reply back to me and I will send it
  985.  DP> in an UUencoded form.
  986.  
  987. You are welcome to do so on YOUR OWN DOLLAR.  That means by netmail only.
  988.  This echo is not for the private exchange of binary code so UUEncoded files
  989. are not permitted here.
  990.  
  991. Moderator
  992.  
  993. --- TC-ED   v2.01  
  994.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  995.  * Tossed by SFToss/286 v1.02a on 92/12/25  15:57:34
  996.  
  997. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  998.  
  999. Conference 4
  1000. Date       12-24-92 20:14:00
  1001. From       Trevor Carlsen
  1002. To         John Reid
  1003. Subject    Re: BP 7 difference
  1004.  
  1005.  
  1006.  
  1007.  JR>  ... It even effects TeeCee's latest
  1008.  JR>  contest, doen't it?
  1009.  
  1010. Not really.  The file has been created already so the sorting of it does not
  1011. require any reference to the random function.  For those creating the file
  1012. for their own testing - well yes, they would be testing on a different file.
  1013. However I fail to see how that could affect their algorithms or design. 
  1014.  
  1015. TeeCee
  1016.  
  1017. --- TC-ED   v2.01  
  1018.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1019.  * Tossed by SFToss/286 v1.02a on 92/12/25  15:57:34
  1020.  
  1021. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1022.  
  1023. Conference 4
  1024. Date       12-23-92 20:01:00
  1025. From       Dj Murdoch
  1026. To         Mark Ouellet
  1027. Subject    Re: Windows API Call
  1028.  
  1029.   MO>     C and C++ can be told to use Pascal convention when passing
  1030.  MO>     parameters
  1031.  
  1032.  MO>     Pascal can't be told to use C convention.
  1033.  
  1034.  MO> So if you intend to compile assembler, Pascal or C routines useable by
  1035.  MO> both you had better make it Pascal convention. Since it's the only
  1036.  MO> standard they both can use.
  1037.  
  1038. Why couldn't Pascal use the C convention?
  1039.  
  1040. --- Msg V3.2
  1041.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  1042.  * Tossed by SFToss/286 v1.02a on 92/12/25  15:57:35
  1043.  
  1044. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1045.  
  1046. Conference 4
  1047. Date       12-24-92 00:34:00
  1048. From       Dj Murdoch
  1049. To         All
  1050. Subject    TP 6 bug list update
  1051.  
  1052.  I'm planning to produce one final update to my TP 6 bug list (the current version
  1053. is available on PDN sites as tp6bugs6.zip).  If anyone knows of any bugs that
  1054. aren't in that list or the list below, please let me know as soon as possible.
  1055. Demonstration code is nearly essential; I try to confirm any bugs that I put
  1056. in my list. 
  1057.  
  1058.  
  1059. The FLDLN2 instruction (which is valid on an 8087) triggers error 159, "286/287
  1060. instructions are not enabled" when compiled in the $N+,G- mode.  (Fixed in
  1061. BP 7.)
  1062.  
  1063. The string formatting routines get the 19th digit wrong on very large Comp
  1064. numbers. (Not fixed in BP 7.)
  1065.  
  1066. The TDSTRIP utility which comes with the professional version of TP damages
  1067. the .EXE header:  the min extra paragraphs field is set to 0. (See STRIPPED.ZIP
  1068. in TP6BUGSn.ZIP for a damage detector).  (Fixed in BP 7.)
  1069.  
  1070. Actual heap allocation can be 511 bytes more than the maximum specified in
  1071. the $M directive. (Not fixed in BP 7.)
  1072.  
  1073.  
  1074.  
  1075. --- Msg V3.2
  1076.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  1077.  * Tossed by SFToss/286 v1.02a on 92/12/25  15:57:41
  1078.  
  1079. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1080.  
  1081. Conference 4
  1082. Date       12-24-92 00:36:00
  1083. From       Dj Murdoch
  1084. To         All
  1085. Subject    BP 7 bug list
  1086.  
  1087.  I've decided to try to continue my unofficial bug list with the DOS parts of
  1088. BP 7.  I've checked a lot of the TP 6 bugs in the new version; besides the
  1089. leftovers, I've come up with 11 new ones.  If you know of any others than
  1090. the ones below, please let me know.  In a few days or so, I'll put together
  1091. a full list that includes all fixes and patches, and send it out on PDN.
  1092.  
  1093.  
  1094. 28. Coprocessor errors are reported with the address normalized, but the IDE
  1095. can't find source lines with errors specified that way.  Use the command line
  1096. compilers with /F ssss:oooo to find them.
  1097.  
  1098. 29. On a 386, a longint shift of 16 bits or more is unreliable. (A fix is
  1099. available in NEWSHR.FIX.)
  1100.  
  1101. 30. On a 386, interrupt routines must save the extended registers EAX through
  1102. to EDX or risk corrupting longint calculations.
  1103.  
  1104. 31. On a 386, longint calculations are unreliable in environments (like certain
  1105. Novell netware versions) which don't preserve the extended registers. (The
  1106. only "fix" to BP is to turn off 386 operations by executing Test8086=0 at
  1107. the start of your program, if you can't get the buggy netware fixed.)
  1108.  
  1109. 32. The DisposeNode procedure in the Outline unit neglects to dispose of the
  1110. Text string. (A fix is available in OUTLINE.FIX.)
  1111.  
  1112. 33. Overflow checking $Q+ sometimes misses overflows in operations on bytes.
  1113.  
  1114. 34. The file dialog in STDDLG.PAS messes up directory changes.  (A fix is
  1115. available in FILEDIAL.FIX.)
  1116.  
  1117. 35. Spurious compiler arithmetic overflow errors are generated in constant
  1118. expressions containing products of negative numbers with zero.
  1119.  
  1120. 36. If a running program changes a file that's currently loaded in the IDE,
  1121. when you exit you'll lose the IDE version no matter how you answer the dialog
  1122. about which version to keep.
  1123.  
  1124. 37. The expression "Word(hi(wordvar))" doesn't zero-extend the high byte of
  1125. wordvar to give a word, it gives the word from memory starting at the location
  1126. of the high byte of wordvar, i.e. the high byte plus the low byte of the next
  1127. variable.
  1128.  
  1129. 38. With the extended syntax $X+, asciiz character arrays that are fields
  1130. in records passed as const parameters aren't handled properly by Writeln.
  1131.  (This bug report clearly needs some work!)
  1132.  
  1133. --- Msg V3.2
  1134.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  1135.  * Tossed by SFToss/286 v1.02a on 92/12/25  15:57:41
  1136.  
  1137. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1138.  
  1139. Conference 4
  1140. Date       12-23-92 00:00:00
  1141. From       Terry Hughes
  1142. To         Jud Mccranie
  1143. Subject    Re: B-tree problem
  1144.  
  1145.  
  1146. JM>Later: I think I found the problem.  The data and program are on
  1147. JM>drive C of the server.  The network drive is F.  The guy here told
  1148. JM>me that running on C or on F on the server was the same thing.  But
  1149. JM>it seems that when the program running on the server is on C it
  1150. JM>doesn't know that it is really on the network.  In that case, it
  1151. JM>and a W.S. may have the same # (it happened again), but it only
  1152. JM>happened when the program on the server was going to drive C instead
  1153. JM>of the network drive (which may have other bad consequences).
  1154.  
  1155. The workstation number (really, internal dialog number) is now
  1156. associated with a fileblock's dialog file. If two workstations are using
  1157. different dialog files (as sounds like is happening with your C/F drive
  1158. mapping) then it is possible for them to get identical workstation
  1159. numbers. However, if two programs are using different dialog files then
  1160. nothing is going to work right (workstation numbers or locking in
  1161. general).
  1162.  
  1163. Here's another thought...the unique workstation numbers are achieved by
  1164. locking portions of the dialog file. Perhaps you really are working with
  1165. the same dialog file (referenced by C: or F:) but the network shell
  1166. doesn't recognize it as such (due to the C/F mapping) and is making
  1167. separate entries in its lock table. As with the first scenario, this
  1168. will cause many more problems then just duplicate workstation numbers.
  1169.  
  1170. JM>One more thing - it assigns a number 1 .. 50 (default) to each
  1171. JM>workstation's fileblock.  Does that limit you to 50 workstation/FB
  1172. JM>combinations, or can each FB have 50 workstations on it?  That is,
  1173. JM>with 7 file blocks open at once, is that going to limit it to
  1174. JM>50/7 = 7 workstations?
  1175.  
  1176. The limit is 50 workstations (controlled by MaxNrOfWorkstations) per
  1177. fileblock.
  1178.  
  1179. Here's a thumbnail sketch of how workstation numbers work now that might
  1180. help you understand some of these issues better: Each fileblock's dialog
  1181. file now maintains the "list" of workstation numbers. BTOpenFileBlock
  1182. gets a workstation number by attempting to lock a single byte of the
  1183. dialog file representing workstation one. If that byte is already locked
  1184. it means some other workstation has already been assigned the number
  1185. one. So, BTOpenFileBlock tries to lock the next byte -- and so on. If it
  1186. eventually succeeds then the byte it locked is the workstation number;
  1187. if all 50 bytes are already locked then BTOpenFileBlock fails.
  1188.  
  1189. -Terry
  1190.  
  1191. ___
  1192.  X QMPro 1.0 41-2187 X TurboPower Software (voice 719-260-6641)
  1193.  
  1194. --- Maximus 2.01wb
  1195.  * Origin: The Programmers Playhouse (1:128/60)
  1196.  * Tossed by SFToss/286 v1.02a on 92/12/26  09:47:22
  1197.  
  1198. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1199.  
  1200. Conference 4
  1201. Date       12-23-92 00:00:00
  1202. From       Terry Hughes
  1203. To         Luis Martin
  1204. Subject    Object Professional 1.1
  1205.  
  1206.  
  1207. LM>Does OPRO have an unlimited-size-file editor ?
  1208.  
  1209. No. OPRO has several editors but all are limited to 64K. However, one of
  1210. our tech support guys wrote a very similar editor (in form and
  1211. capabilities) that is limited only by available heap space and that
  1212. editor (OPBIGED.LZH, I think) is available on our BBS. I believe he
  1213. later used the VIRTMEM unit from Analyst that I mentioned to make that a
  1214. true virtual editor but I don't think we've made that generally
  1215. available yet.
  1216.  
  1217. LM>From your words it seems OPRO lacks a virtual memory
  1218. LM>manager, but Turbo Analyst has it. (Source included?)
  1219.  
  1220. Correct. OPRO does not have a virtual memory manager; Turbo Analyst does
  1221. and it includes complete source code.
  1222.  
  1223. LM>First of all, I don't know if OPRO would let me use
  1224. LM>unlimited size TCollections or something similar to
  1225. LM>unlimited TCollections, besides the unlimited size editor.
  1226.  
  1227. OPRO doesn't do anything to extend TCollections or any other component
  1228. of TV. OPRO has a wide variety of container classes (lists, stacks,
  1229. queues and large arrays) but none of these are unlimited. The large
  1230. array facility probably comes closest, being able to virtualize arrays
  1231. to EMS, XMS or disk (up to 16 megs).
  1232.  
  1233. LM>I supose the change form TV to OPRO is less troublesome
  1234. LM>than switching from not-event-programming to TV, but how
  1235. LM>many hours or days do you think would it cost to make the
  1236. LM>transition ?
  1237.  
  1238. That question is too subjective and has too many variables for me to
  1239. give you meaningful answer. Popular opinion seems to be that OPRO is
  1240. easier to learn than TV. And OPRO definitely provides more functionality
  1241. "out of the box." However, if you've already committed to and mastered
  1242. TV then these points probably don't matter much.
  1243.  
  1244. LM>From the comments I've read most people rate OPRO very
  1245. LM>high, and I think it must be very good stuff, but the lack
  1246. LM>of virtual memory, in my case, would make its purchasing
  1247. LM>very hard to justify.
  1248.  
  1249. OPRO has a couple of thousand functions that can probably save you lots
  1250. of programming time and effort, but a virtual memory manager isn't one
  1251. of them.
  1252.  
  1253. LM>I don't need Turbo Analyst, but I'd be glad to hear any
  1254. LM>sugestions you'd have for me.
  1255.  
  1256. I'm not sure what else to suggest. You say you need a virtual memory
  1257. manager, which Analyst has, but you don't need Analyst?
  1258.  
  1259. I guess you could go with one of the commercially available virtual
  1260. memory managers. Last time I checked in the Programmer's Connection
  1261. catalog there were at least two virtual memory products that worked with
  1262. Turbo Pascal but both were in the $200 to $300 (discounted) range.
  1263.  
  1264. You might want to try searching for a public domain or shareware unit. I
  1265. don't ever recall seeing one but I never really looked.
  1266.  
  1267. -Terry
  1268.  
  1269. ___
  1270.  X QMPro 1.0 41-2187 X TurboPower Software (voice 719-260-6641)
  1271.  
  1272. --- Maximus 2.01wb
  1273.  * Origin: The Programmers Playhouse (1:128/60)
  1274.  * Tossed by SFToss/286 v1.02a on 92/12/26  09:47:22
  1275.  
  1276. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1277.  
  1278. Conference 4
  1279. Date       12-24-92 22:15:00
  1280. From       Dj Murdoch
  1281. To         Chris Priede
  1282. Subject    Re: exe's
  1283.  
  1284.   DM> When COMMAND.COM runs your program, it puts the full DM> pathname in;
  1285. that's why you usually see it there.
  1286.  
  1287.  CP>         That is correct, however, any responsible program should do the
  1288.  CP> same as many other programs rely on it. 
  1289.  
  1290. It turns out I was wrong.  COMMAND.COM *does not* put the full pathname there;
  1291. it puts the path as it appears in the PATH environment variable.  If you have
  1292. a relative path like "BIN" or ".." there, then Paramstr(0) won't contain a
  1293. full path, it'll contain a relative path.
  1294.  
  1295. So any program that relies on a full path in Paramstr(0) is liable to run
  1296. into trouble sometime.  Don't do it.
  1297.  
  1298. --- Msg V3.2
  1299.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  1300.  * Tossed by SFToss/286 v1.02a on 92/12/26  09:47:41
  1301.  
  1302. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1303.  
  1304. Conference 4
  1305. Date       12-24-92 22:19:00
  1306. From       Dj Murdoch
  1307. To         Jud Mccranie
  1308. Subject    Re: Break & continue
  1309.  
  1310.   JM> How do you feel about break and continue?
  1311.  
  1312. I used to really miss them, since I used them quite a lot in Ratfor.  Now
  1313. I've had BP 7 for over a month and haven't used either yet.
  1314.  
  1315.  JM> A minor quibble: they are called procedures rather than reserved words.
  1316.  JM> However, they fit the syntax of a procedure instead of a reserved word.
  1317.  
  1318. This is an advantage:  if they had been reserved words, then you wouldn't
  1319. be allowed to have variables called Break and Continue, and that might have
  1320. messed up some existing programs.  Just adding Library to the reserved word
  1321. list meant I had to go through several OPro files changing all Library's to
  1322. TLibrary's.  It's also consistent with the fact that Halt and Exit are procedure
  1323. , not reserved words.
  1324.  
  1325.  JM> Next: they sort of violate the philisophy of Pascal. I use them any way.
  1326.  
  1327. I don't see how they violate anything; could you elaborate?
  1328.  
  1329.  JM> Finally, and most seriously, their use is not robust.  That is, they
  1330.  JM> can be very error prone.  You can have a BREAK or CONTINUE working
  1331.  JM> right, and then insert another loop (say for input validation) and
  1332.  JM> invalidate the program.  That is all to easy to do.  
  1333.  
  1334. I know the problem, but I don't think they're any less robust than the alternati
  1335. e of flag variables, and they're considerably more robust than the GOTO alternat
  1336. ve.
  1337.  
  1338.  JM> In that sense,
  1339.  JM> they are worse than GOTO, since with GOTO you always know where you're
  1340.  JM> going to.  
  1341.  
  1342. The trouble is, you don't.  Say you have two loops in a procedure, and you
  1343. always use Break as the label to jump to when you get out of a loop.  You
  1344. might then use Break1 and Break2, but what if you make a typo and jump to
  1345. the wrong one?  The compiler won't complain a bit.
  1346.  
  1347.  
  1348.  
  1349. --- Msg V3.2
  1350.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  1351.  * Tossed by SFToss/286 v1.02a on 92/12/26  09:47:41
  1352.  
  1353. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1354.  
  1355. Conference 4
  1356. Date       12-25-92 08:18:00
  1357. From       Dj Murdoch
  1358. To         Steve Connet
  1359. Subject    Re: Pointers
  1360.  
  1361.   SC> Should I use NEW & DISPOSE or GETMEM & FREEMEM?
  1362.  
  1363.  SC> From what I understand, GetMem & FreeMem only allows a maximum of 64k to
  1364.  
  1365.  SC> be allocated.  Is there a limit to New & Dispose?
  1366.  
  1367.  SC> My Record is 97 bytes long.  Within the 64k barrier, a simple
  1368.  SC> calculation will tell me that I would only be able to read in 675
  1369.  SC> Records from disk with GetMem & FreeMem.
  1370.  
  1371. No, I think you've misunderstood the book.  GetMem and New are really the
  1372. same procedure; the only difference is that New gets the size from the type
  1373. of the thing you're allocating.  There's a limit of 64K *per allocation*,
  1374. but no limit on total allocations other than the size of your heap.  (In fact,
  1375. yesterday I allocated 16 Megabytes of variables in a test of the protected
  1376. mode of BP 7!).
  1377.  
  1378.  SC> How about New & Dispose?  If my disk file contained 2500 records at 97
  1379.  SC> bytes each, a simple calculation will tell me that I need 237K of memory
  1380.  SC> to hold those in memory.  Do you use New & Dispose in conjunction with
  1381.  SC> the functions MemAvail and MaxAvail to monitor memory?
  1382.  
  1383. Yes, it's a very good idea to check MaxAvail before doing an allocation. 
  1384. If you don't, it may fail and abort your program.  (You can change this default
  1385. behaviour and have it return Nil, but it's better to keep your program simple
  1386. for now, because working with a Nil pointer is likely to cause more trouble
  1387. than just an abort.)
  1388.  
  1389.  
  1390. --- Msg V3.2
  1391.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  1392.  * Tossed by SFToss/286 v1.02a on 92/12/26  09:47:53
  1393.  
  1394. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1395.  
  1396. Conference 4
  1397. Date       12-25-92 08:24:00
  1398. From       Dj Murdoch
  1399. To         Scott Samet
  1400. Subject    Re: ..
  1401.  
  1402.   SS> I've seen one out there.  It did what you mentioned, plus 
  1403.  SS> changed all indentifiers to strings of I, 1, O and 0.  Be 
  1404.  SS> sure to keep a large bottle of extra strength Excedrin 
  1405.  SS> when you try to figure out stuff like:
  1406.  
  1407.  SS>     For I011O1I111 := I11O1I00O to O01I1011
  1408.  
  1409.  SS> I'll see if I can find this beauty and send you a copy.
  1410.  
  1411. Yes, please do!!  I hope it's something that can be freely distributed.
  1412.  
  1413. --- Msg V3.2
  1414.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  1415.  * Tossed by SFToss/286 v1.02a on 92/12/26  09:47:53
  1416.  
  1417. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1418.  
  1419. Conference 4
  1420. Date       12-25-92 08:43:00
  1421. From       Dj Murdoch
  1422. To         Peter Davies
  1423. Subject    Re: move()
  1424.  
  1425.   PD> I've been playing around with DOS protected mode in BP7 
  1426.  PD> and have a memory block larger than 64k allocated.  The 
  1427.  PD> problem is I need to MOVE data across the 64k boundaries.  
  1428.  PD> That is, say i might say move at 63k for a length of 5k.  
  1429.  PD> What actually happens is that move() wraps around, and 
  1430.  PD> does not perform as I originally expected.  Does anyone 
  1431.  PD> have a fix for this, or could anyone write one?  
  1432.  
  1433. I don't have a fix, but here's the idea of one:
  1434.  
  1435. 1.  Given the start pointer and size to move, figure out how to break up the
  1436. source so that no part crosses a 64K boundary.  Then you'll have blocks of
  1437. 64K or less to move, always originating in a single segment.
  1438.  
  1439. 2.  To move one of those blocks, look at the size and the destination.  If
  1440. it crosses a 64K boundary, it'll need to be moved in two parts.
  1441.  
  1442. You'll have to do a lot of fooling around with SelectorInc to get the addressing
  1443. right.  See the manual (the Language Guide, I think) for the details on that. 
  1444.  
  1445.  
  1446. It's not going to be trivial, but should be doable.  However, I think it would
  1447. probably be simpler not to bother with the huge blocks; just do things the
  1448. way you would in real mode, with arrays of pointers to blocks.  You're already
  1449. doing that in effect, with all the work involved in 1 and 2 above.
  1450.  
  1451. --- Msg V3.2
  1452.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  1453.  * Tossed by SFToss/286 v1.02a on 92/12/26  09:47:53
  1454.